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(54) Method and system for autonomous spacecraft control 

(57) An autonomous control system supports 
autonomous operation of the a spacecraft in can-ying 
out mission objective commands. The control system 
also provides autonomous fault detection, isolation and 
recovery Performance problems and anomalies are 
detected and accounted for in the carrying out mission 
objectives. A mission manager nxxfule analyzes all 
incoming mission objective commands to verify that suf- 
ficient system resources are available and not already 
dedicated to other pendhig mission objective com- 
mands. A command processor is included to translate 
acceptable mission objective commands into tower level 
command sequences for delivery to a flight manager 
controlling the underlying spaceaaft systems. The mis- 
sion manager reanalyzes all pending mission objective 
commands whenever unexpected performance or fault 
conditions are detected. The mission objective com- 
mands can be constructed in a hierarcNcal fashion, with 
many sequences predefined within the spacecraft All 
portions of the autonomous control system, including 
software and associated data, can be readily replaced, 
supplemented or disabled at any time before, during or 
after launch. 
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Description 
BACKGROUND 

1. Technical Reld 5 

The present invention relates generally to autono- 
mous spacecraft control systems: and. specifically, it 
relates to on-board control systems which manage 
spacecraft operational systems, including performance 10 
monitoring and feult detection with adaptive fault recov- 
ery and performance optimization with tittle, if any. 
assistance from ground-based support. 

2. Related Art is 

Fig. 1 is a schematic block diagram of a conven- 
tional spacecraftis interaction with ground based sup- 
port. Particularly, a spacecraft 101 operates pursuant to 
sequences of low level commands (hereinafter "LLCs") so 
received from remote ground support 103 via wireless 
transceivers 105 and 107. Ground support personnel 
work with monitoring and control systems 109 to formu- 
late such LLC sequences to carry out a mission. 

In rTK>st cases, to generate an LLC sequence, the 25 
personnel and the monitoring and control systems 109 
must be aware of the current operating status of the 
spacecraft 101. Thus, a flight manager 111 is charged 
with continuously collecting data (hereinafter "monitor- 
ing data") received from pluralities of sensors 113 that 30 
monitor various spaceaaft resources and hardware. 
The flight manager 111 must send the monitoring data 
and status information generated by the flight manager 
1 1 1 to ground support 103. However, because of limita- 
tions in bandwidth, ground support 103 must direct the 35 
flight manager 1 1 1 to only send the portions 0I the avail- 
able monitoring data and status inlbrmation (together 
referred to hereinafter as Idata streams!) that currently 
seem most important. 

As the data streams are received, the personnel 40 
and the monitoring and control systems 109 must ana- 
lyze the data streams, and, if necessary, identify, nxxiify 
or create LLC sequences for delivery to the spacecraft 
101. The monitoring and control systems 109 transmit 
the LLC sequences to the spacecraft 101 where they 45 
are executed by a flight manager 111. The LLC 
sequences might, for example, direct the flight manager 
111 to adjust one of actuators 115. disable or enable 
one of the sensors 113, and/or initiate operation of a 
payload processor 1 1 7 to manipulate a payload 119. so 

Additionally, through continuous monitoring and 
analysis of the spaceaaft data streams, the ground 
support 103 attempts to detennine the success or fail- 
ure of LLC sequences executed by the flight manager 
111. If. for example, an LLC sequence caused a mis- ss 
alignment of the spacecraft 101 as determined through 
monitoring and analyzing subsequent data streams 
received.. the ground support 103 must attempt to gen- 
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erate a new LLC sequence (and possisly others there- 
after) with hopes of achieving alignment. 

Calculations needed to generate the^LLC sequence 
become quite complex even for seemingly easy tasks 
due to changing spacecraft conditions. Such calcula- 
tions typically involve an analysis of current spacecraft 
data streams to predict the future status of the space- 
aaft 101 (e.g.. orientation, velocity, acceleration, hard- 
ware operations, etc.) when an LLC sequence will be 
executed. The LLC sequences must be constructed 
and/or adjusted based on the prediction. If the predic- 
tion proves inconect (e.g.. due to unexpected changes 
in spacecraft conditions or system performance), the 
desired impact of the LLC sequences is generally not 
achieved. Thereafter, con-ective action must be taken in 
the form of further LLC sequences which again rely on 
further predictions of future spacecraft status, which 
may again prove inconrect. Communication propagation 
times, available t)andwkith constraints and ground sup- 
port and spacecraft processinglimes often exacert)ate 
the problem. 

Compounding matters, there is an ever inaeasing 
demand on spacecraft performance to meet mission 
goals requiring travel to many destinations over longer 
distances to perform greater numbers of more complex 
operations. Conespondingly. spacecraft designers are 
charged with the onerous tasks of meeting such 
demands while reducing costs and inaeasing reliabil'ity. 
As a result, using tiie structure and operation set forth in 
Fig. 1. designs for both general purpose (and some- 
times reusable) spacecraft and con^esponding general 
purpose ground support systems have been attempted. 
The general purpose spacecraft and ground support 
are supposed to accommodate a wide variety of antici- 
pated or potential missions. To accomnxxlate such gen- 
eral purpose design, overall system complexity has 
dramatically increased. 

Thus, to accommodate conventional spacecraft, 
ground support systems require very conplex and 
costiy nrtonitoring and control systems capable of 
receiving and rapidly processing large amounts of 
spaceaaft data so tfiat accurate identification, genera- 
tion and/or modification to LLC sequences can be 
achieved. The ground support systems must also be 
able to identify and overcome anamdous trends, and 
rapidly identify, isolate and recover from both spacecraft 
and ground system faults. As a design goal, the control, 
adjustment and recovery of a spacecraft should be pos- 
sible under all circumstances. As can be appreciated, 
with conventional designs, this goal is not easily met 

SUMIMARY OF THE INVENTION 

Various aspects of the present invention may be 
found in a spaceaaft system having a ground-based 
system and a spacecraft. Within the spacecraft, a flight 
manager controls a plurality of actuators pursuant to 
any of a plurality of lower level commands. The flight 
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manager is also coupled to a plurality of sensors that 
produce data indicative of tfie operational status of the 
spacecraft. A transceiver within the spacecraft is capa* 
ble of receiving selected ones of the plurality of lower 
level commands from the ground-based system des- 
tined for the flight manager. It is also capat)le of receiv- 
ing selected ones of a plurality of higher level 
commands that represent the plurality of mission objec- 
tives. Additionally, an autonomous control system 
autonomously attempts to carry out the plurality of mis- 
sion objectives through scheduling and occasionally 
rescheduling of the selected ones of the plurality of 
higher level commands received k>y the transceiver. The 
autonomous control system also generates, from the 
selected ones of the plurality of Ngher level commands, 
sequences of lower level commands that are delivery to 
the flight manager. 

Other aspects can t>e found in several of many var- 
iations In the spacecraft system. For example, the 
autonomous control system may comprise a fault detec- 
tion and recovery module that analyzes the data pro- 
duced t)y the plurality of sensors to detect and attempt 
recovery from fault conditions in the operational status 
of the spacecraft. The autonomous control system may 
further comprise a mission agent that responds to the 
fault detection and recovery module by attempting to 
reschedule the selected ones of the plurality of higher 
level commands to accommodate detected fault condi- 
tions. Similarly, the autonomous control system may 
comprising a performance analyst that analyzes the 
data produced by the plurality of sensors to detect and 
attempt accomnrxxjation of unexpected performance in 
the operational status of the spacecraft. As such, a mis- 
sion agent may be included that responds to the per- 
formance analyst by attempting to reschedule the 
selected ones of the plurality of higher level commands 
to accommodate the unejqDected performance 
detected. A command processor may be added that 
performs the generation, from the selected ones of the 
plurality of higher level commands, of sequences of 
lower level commands that are delivery to the flight 
manager. Many other variations are possible. 

Further aspects may be found in other embodi- 
ments as well. Specifically, an alternate spacecraft, hav- 
ing an operational status, may be used to carry out a 
plurality of mission objectives. This spacecraft may 
comprise a plurality of sensas producing data indica- 
tive of the operational status of the spacecraft and a plu- 
rality of actuators as before. A controller, 
communicatively coupled to control the plurality of actu- 
ators, operates pursuant to instructions received. An 
analyzer communicatively couples to the plurality of 
sensors to monitor and e/aluate the data produced. A 
mission manager, communicatively coupled to the ana- 
lyzer, schedules and occasionally reschedules instruc- 
tions for the corttroller to autonomously carry out the 
plurality of mission objectives. 

Again, many variations are possUe. For example, 



the analyzer may comprise a fault detection and recov- 
ery module that analyzes the data produced by the plu- 
rality of sensors to detect and attempt recovery from 
fault conditions in the operational status of the space- 

5 aaft. Therein, the mission manager responds to the 
fault detection and recovery module by attempting to 
reschedule the instructions for the controller to accom- 
modate detected fault conditions. The analyzer may 
alternatively or additionally comprise a performance 

10 analyst that analyzes the data produced by the plurality 
of sensors to detect and attempt accommodation of 
unexpected performance in the operational status of the 
spacecraft In either case or otherwise, the sequences 
of the instructions used by the spacecraft can be stored 

75 within the spacecraft in a hierarchical arrangement 

In another embodiment, a spacecraft comprises a 
mission manager, communicatively coupled to an ana- 
lyzer, that schedules and occasionally reschedules 
higher level instructions to autonomously carry out the 

20 plurality of mission objectives. A command processor, 
communicatively coupled to receive scheduled higher 
level instructions from the mission manager, generates 
lower level instructions from the higher level instructions 
received. A control module, communicatively coupled to 

25 control the plurality of actuators, operates pursuant to 
lower level instructions received from the command 
processor. The many aforementioned variations may 
also apply. In addition, for example, the spaceaaft may 
further conprise a library that contains sequences of 

30 the lower level instructions, and the command proces- 
sor generates lower level instructions for each of the 
higher level instructions by referencing the library. 
Revealing other aspects of the present invention, a 
spacecraft system comprises a spacecraft capable of 

35 carrying out a plurality of mission objectives. The sys- 
tem also contains a plurality of ground units each having 
a ground transceiver. Disposed on the spacecraft, a 
flight manager controls a plurality of actuators pursuant 
to any of a plurality of lower level commands. A space- 

40 craft transceiver can receive and route one of the plural- 
ity of lower level commands from at least one of the 
plurality of ground units to the flight manager. An auton- 
omous control system carries out one of the plurality of 
mission objectives through receipt, scheduling and 

45 occasionally rescheduling of higher level commands. 
The autonomous control system translates the higher 
level commands into sequences of lower level com- 
mands for delivery to the flight manager. 

In addition, at least one of ttie plurality of ground 

so units may comprise a ground support system, while 
another may comprise a transmitter having a user irtter- 
face to initiate delivery of one or more higher level com- 
mands to the autonomous control system via the 
spacecraft transceiver. Previously mentioned and many 

55 other variations also apply. 

Further aspects of the present invention will be 
apparent from the following detailed description, taken 
In connection with the accompanying drawings, and 
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from the individual features and relationships of the 
respective appended claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 Is a schematic block diagram of a conven- 
tional spacecraftfs Interaction with conventional ground 
based control systems, used to illustrate several of 
many problems associated therewith. 

Fig. 2 is a schematic block diagram of an autono- 
mous spacecraft and ground support systems built in 
accordance with the present Invention that illustrates 
autonomous operation and control of spacecraft opera- 
tions to accomplish mission objectives. 

Rg. 3 is a schematic block diagram an exemplary 
embodiment the autonomous spacecraft and ground 
support systems of Fig. 2. used to illustrate features 
such as autonomous fault detection, identification and 
recovery processing and autonomous mission anomaly 
or trend detection and accommodation in accordance 
with the present invention. 

Fig. 4 is a schematic block diagram providing a 
detailed implementation of the autonomous spaceaaft 
of Fig. 3 built in accadance with the present invention. 

Fig. 5 is an exemplary flow diagram that illustrates 
much of the functionality of the mission manager found 
within the embodiment of the autononKXJS spacecraft of 
Fig. 4 in accordance with the present invention. 

Rg. 6 is an exemplary flow diagram that illustrates 
much of the functionality of the fault analyst and safe 
mode operations found within the eml>odiment of the 
autonomous spacecraft of Rg. 4 in accordance with the 
present invention. 

Fig. 7 is an exemplary flow diagram that illustrates 
much of the functionality of the mission analyst found 
within the embodiment of the autonomous spacecraft of 
Fig. 4 in accordance with the present invention. 

DETAILED DESCRIPTION 

Rg. 1 is a schematic block diagram of a conven- 
tional spacecraftis interaction with conventional ground 
based control systems, used to illustrate several of 
many prot)lems associated therewith. As previously dis- 
cussed in the background section above, the conven- 
tional spacecraft 101 operates pursuant to LLC (Low 
Level Command) sequences constructed at ground 
support 103 by the monitoring and control systems 109. 
To accommodate such control, the conventional space- 
craft 101 delivers continuous data streams to the moni- 
toring and control systems 109 for analysis. Within the 
conventional spacecraft 101. the flight manager ill 
receives and executes LLC sequences received, and 
captures and delivers sensor and other operational data 
and status in16rmatk)n through the transceivers 1 07 and 
105 to the monitoring and control systems 109. 

Rg. 2 is a schematic block diagram of an autono- 
mous spacecraft and ground support systems built in 



accordance with the present invention that illustrates 
autonomous operation and control of spaceaaft opera- 
tions to accomplish mission objectives.^ecifically. an 
autonomous spacecraft 201 comprises an autonomous 

5 control system 203 placed, for example, within a con- 
ventional spacecraft such as that of Fig. 1. Within the 
autonomous spacecraft 201 conventional hardware 
and/or software components such as a transceiver 205. 
a flight manager 207. actuators 209. sensors 21 1. a 

10 payload processor 213 and a payload 215 can be found. 
Although possit)le and potentially desirable in some cir- 
cumstances, such underlying conventional components 
and their interactions need not be modified to accom- 
modate the autonomous control system 203. 

15 Within the autonomous control system 203, a mis- 
sion controller 217 Is charged with candying out one or 
more mission goals 219. From the mission goals 219» 
the mission controller 217 generates mission plans 221 
which provide scheduling inforrriation indicating how the 

20 autonomous spaceaaft 201 will operate to carry out the 
mission goals 219. Following the plans 221 . the mission 
controller 21 7 generates and delivers LLC sequences to 
the flight manager 207 when appropriate so that the 
flight manager 207 can carry out the underlying mission 

25 goals 219. 

The mission controller 217 monitors data streams 
from the flight manager 207 as would such conventfonal 
ground support. The mission controller 217 selectively 
uses the data streams not only to determine the suc- 

30 cess or Mure of a delivered LLC sequence, but also to 
monitor the operational status of the autonomous 
spacecraft 201. In particular, the mission controller 217 
utilizes one or nrore mission goals 219 to generate mis- 
sion plans 221 . The mission goafs 219 may have been 

35 communicated before, during or at any time after 
launch. A mission goal ought, for example, be to per- 
form a delta V on a particular date, at a particular time 
and for a desired duration. Another mission goal might 
be to take Infrared pictures of a region on earth within a 

40 specific range of time each day for multiple consecutive 
days in resp>onse to a field commanderis request. 
Instead of formulating LLC sequences to carry out such 
mission goals at ground support 251 . the mission goals 
themselves are delivered by ground support 251 to the 

45 mission controller 21 7. 

Upon receipt and verification of a new mission goal, 
the mission controller 21 7 begins planning and schedul- 
ing using its knowledge of the status of spacecraft hard- 
ware and software systems, resource availabifity. arvi 

so mission performance profiles (e.g.. fault status, fuel 
remaining, perceived battery discharge rates, etc.) to 
aeate a plan that achieves the new mission goal. 

The mission controller 217 considers other mission 
goals and plans when generating a plan for a new ntis- 

55 sion goal. Doing so may result In alternate or modified 
plans for canying out other mission goals. 

The mission controller 217 also identifies missfon 
goals which cannot be carried out due to direct conflict 
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with other mission goals or due to impossibiiity with pro- 
jected or actual spacecraft resources and system limita- 
tions. Upon such occurrences, the mission controller 
217 communicates with ground support 251 for resolu- 
tion. 5 

The mission controller 217 reconsiders all plans for 
can'ying out mission goals whenever system resources 
(actual or projected) become unavailable, e.g.. through 
component fault. Similarly, such reconsideration occurs 
whenever a change in system performance is detected. io 
e.g.. where anomalies or trends in performance are 
found. For example, the detection of an inaccurate pre- 
diction of fuel consumption triggers a reconsideration of 
all pending mission goals to verify that they can be 
accomplished. Through such ongoing planning and is 
replanning, the mission controller 217 attempts to can^y 
out all mission goals received no matter what state the 
spacecraft 201 happens to be in. The mission controller 
217 also attempts to fbrnuilate mission plans that mini- 
mize strain on system resources. 20 

Ground support 251 comprises a transceiver 253. 
support systems 255 and a test bed 257. As previously 
mentioned, ground support 251 does not control the 
autonomous spacecraft 201 to carry out typical mission 
goals in most circumstances. Howler, the support sys- 25 
terns 255 maybe used to take over control of the space- 
craft 201 should the mission controller 217. for example: 
1) fail to resolve conflicting mission goals; 2) be incapa- 
ble of carrying out an unexpected mission goal; 3) arrive 
at undesirable plans; or 4) suffer from a fault condition. 30 

Thus, personnel using the support systems 255 
have the capability of accessing, replacing or canceling 
previously delivered mission goals at any time. e.g.. to 
address conflicts, terminate goals no longer necessary, 
identify pending mission goals, etc. Likewise, mission 35 
plans 221 may be retrieved, modified and redelivered or 
canceled by the support systems 255. r\/1oreover. if the 
mission controller 217 is not configured to adequately 
generate a mission plan based for example on an unex- 
pected operational maneuver desired, the support sys- 40 
terns 255 can be used to generate and deliver such a 
mission plan to the autonomous control system 21 7 for 
integration with the other of the mission plans 221 . 

Although not typically performed, the ground sup- 
port systems 255 may also be used to generate and 4s 
transmit LLC sequences to the flight manager 207. 
Upon receiving an LLC sequence, the mission controller 
217 relays the sequence to the flight manager 207 for 
execution. The support systems 255 may also direct the 
mission controller 217 to relay data streams related to so 
spacecraft operations to permit the construction of LLC 
sequence and to evaluate the impact of the sequence 
on the autonomous spacecraft 201 . Although the flight 
manager 207 processes LLC sequences without knowl- 
edge of the source of the sequence, the flight manager ss 
207 couM be modified to conskier the source if need 
arises. 

Thus, conventional spaceaaft such as those illus- 



trated in Fig. 1 may be easily equipped with an autono- 
nfK>us control system 217. So equipped, such 
spacecraft operate autonomously to carry out mission 
goals with minimal nronitoring ancLintervention from 
ground support. With their duties relaxed, ground sup- 
port systems and personnel are free to support larger 
numbers of spacecraft than wouM othenmse be possi- 
ble, lowering overall mission costs. And if an autono- 
mous control system fails or proves unsatisfactory or 
insufficient for a given mission, it can be assisted by 
ground support or effectively disabled and replaced by 
ground support. 

Additionally, the mission controller 217 can be 
reprogranvned from the support systems 255. Program- 
ming can be supplemented, replaced or otherwise mod- 
ified to. for example, accommodate unexpected mission 
goals, fix bugs or faults in the mission controller 217 or 
other portions of the spacecraft systems, or support 
debugging. Simitariy, associated data used by the mis- 
sion controller 217 can also be replaced, supplemented 
or modified. Such (re)programming normally takes 
place during development when the spaceaaft 201 or 
components thereof are placed in the test bed 257. 
After development, such as during flight, (re)program- 
ming takes place via the transceivers 253 and 205. In 
this way. deficiencies in an autonomous spacecraft 
(often due to the many unforeseen circumstances pecu- 
liar to a specific mission) can be overcome after launch. 

Although illustrated with independent functionality, 
the functionality of the autonomous control system 217 
might alternatively be integrated partially or entirely into 
the flight manager 207. In fact, the autonomous control 
system 217 might replace the flight manager 207 or 
take over or duplicate some or all of the flight manageris 
functionality. Such approaches work best with new 
spacecraft designs that do not leverage off of conven- 
tional spaceaaft hardware and software components, 
systems and subsystems with proven functional reliabil- 
ity. 

The flight manager 207 typically contains all of the 
functionality traditionally placed in flight software such 
as gukiance. navigation, control, power, global position 
and telemetry handling. It also is usually in direct con- 
tact with the spacecraft bus hardware and payload 
instruments, and. therefore, typically collects and pro- 
vides all measurements and actuator commands. 

Rg. 3 is a schematic block diagram of an exemplary 
embodiment of the autonomous spacecraft and ground 
support systems of Fig. 2. used to illustrate features 
such as autonomous fault detectk)n, identification and 
recovery processing and autonomous mission anomaly 
or trend detection and accommodation in accordance 
with the present invention. With the functionality 
described above with reference to the corresponding 
elements of Rg. 2, an autonomous spacecraft 301 com- 
prises an autononrxxis control system 303. a transceiver 
305. a flight manager 307. actuators 309. sensors 311. 
a payload processor 313, etc. 
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At ground support 351 . personnel use sipport sys- 
tems 355 to deliver mission goals to the autonomous 
control system 303 via the transceivers 353 and 305. 
Such communications are relatively short (in compari- 
son with corresponding LLC sequences), which not only 5 
conserves spacecraft power but also frees the commu- 
nication channel and reduces processing time so that 
the support systems 355 can siniultaneousfy support 
larger numbers of spacecraft. Again, pending mission 
goals, i.e., mission goals awaiting completion within the w 
autonomous control system 303. may be replaced, 
retrieved, canceled, etc.. from the support systems 355. 
If desired. LLC sequences may also be created and 
delivered by the support systems 355. Upon receipt, the 
autonomous control system 303 relays the LLC 75 
sequences to the flight manager 307 for execution. 

Although only one is shown, pluralities of ground 
support systems such as ground support 351 might be 
used with the autonomous spacecraft 301. Further- 
more, such systems may comprise scaled down ver- 20 
sions merely for issuing mission commands and 
reviewing results. For example, a transmitter 375 (which 
may be portable or stationary) is used for sending new 
mission goals to the autonomous spacecraft 301. New 
mission goals are created or selected via a user inter- 25 
face 377. e.g.. a keypad, and sent to the autonomous 
control system 303 via a transceiver 379. The user 
interface 377 might also communicate (via a display 
screen for example) the success, failure or results of the 
mission goal as reported by the autonomous control 30 
system 303 using the transceivers 305 and 379. The 
transmitter 375 might also be configured to receive and 
process specific output from the spacecraft 301 . and/or 
comprise a computing device. 

The autonomous control system 303 comprises a 35 
mission manager 321. a fault analyst 323, an HLC (high 
level command) processor 325 and a mission analyst 
327. Upon receipt of a new mission goal, the mission 
manager 321 initiates a planning and scheduling phase 
wherein attempts are made to reconcile the new mis* 40 
sion goal with all pending mission goals and based on 
the known constraints of the spacecraft 301 . For exam- 
ple, afield commander using a hand-held version of the 
transmitter 375 might formulate a mission goal request- 
ing delivery of a picture taken in the infrared spectrum of 4s 
an enemy location at 12:00 hours. Upon receipt of the 
mission goal, the mission manager 321 uses an on- 
board position trajectory program module and taiowl- 
edge of any pre-planned orbit maneuvers to determine 
where the satellite will be at the requested time. The so 
mission manager 321 then determines if there will be 
sufficient power to enable the infrared instruments to 
image the desired target If it concludes that imaging the 
target requires an attitude maneuver, the mission man- 
ager 321 determines the nfianeuver and its impact on 55 
the systems, resources and other mission goals of the 
autonomous spacecraft 301. This process continues 
until the mission manager 321 detennines whether or 



not an image can be taken. If not. the mission manager 
321 generates a response to the terminal 375 (and pos- 
sibly to ground support 351) indicating^the inability to 
handle the requested mission goal. 

If the mission manager 321 determines that an 
image can be taken, the mission manager 321 delivers 
a desired HLC sequence (hereinafter a "HLC mission 
sequence") to the HLC processor 325. The HLC proc- 
essor 325 breaks the HLC mission sequences into 
smaller subtasks and begins sequencing the com- 
mands. These sequences are refen'ed to hereinafter as 
"LLC mission sequences" and correspond to rather sim- 
ple operations expected by the flight manager 307 such 
as "power up infrared camera" or "capture image." At 
the appropriate times, the HLC processor 325 delivers 
the LLC missk)n sequences to the flight manager 307 
for execution. Likewise, many pending mission goals 
can be simultaneously accomnxxlated through result- 
ing scheduled delivery of potentially interleaving LLC 
mission sequences by the Ht^C processor 325 to the 
flight manager 307. 

During flight, the fault analyst 323 and the mission 
analyst 327 analyze data necessary to detect system 
faults and evaluate mission performance, respectively. 
Upon detecting a fault, the fault analyst 323 attempts to 
isolate the fault. Once isolated, the fault analyst 323 
issues a sequence (or plurality of sequences) of HLCs 
(hereinafter a "HLC recovery sequence") to the HLC 
processor 325 to attempt to recover from the fault. In 
response, the HLC processor 325 translates the HLC 
recovery sequences into one or more LLC sequences 
(hereinafter "LLC recovery sequences"). The LLC 
recovery sequences are combined with the LLC mission 
sequences and delivered, when appropriate, to the 
flight manager 307. 

Similarly, when the mission analyst 327 Wentifies 
performance deviations such as through data trending, 
the mission analyst 327 may attempt to accomnrKxlate 
or adjust for the variations by delivering an HLC 
sequence (hereinafter an "HLC performance 
sequence") to the HLC processor 325. The HLC proc- 
essor 325 responds by translating the HLC perform- 
ance sequence into one or vnote LLC sequences 
(hereinafter "LLC performance sequences"). The LLC 
performance sequences are combined with the LLC 
mission and fault sequences for delivery to the flight 
manager 307. 

In addition, the flight manager 307 can receive LLC 
sequences (hereinafter "LLC ground sequences") 
directiy from ground support 351 or the transmitter 375 
(if so configured). Upon receipt of LLC ground 
sequences, the transceiver 305 merely routes the LLC 
ground sequences to the flight manager 307 for execu- 
tion. Ground support 351 and the transmitter 375 may 
also send HLC sequences (hereinafter "HLC ground 
sequences") directly to the HLC processor 325 with the 
mission manager 321 acting as a relaying device. 

Fig. 4 is a schematic block diagram providing a 
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detailed implementation of the autonomous spacecraft 
of Fig. 3 built in accordance with the present invention. 
An autonomous spacecraft comprises a transceiver 
401 . a mission manager 403. an HLC processor 405, a 
flight manager 407, a fault analyst 409, a mission ana- s 
lyst 411. sensors 415 and actuators 417 which gener* 
ally operate as desaibed in reference to like elements 
of Fig. 3. The autonomous spacecraft also comprises a 
command script database 413. 

A mission goal may comprise a single HLC or may io 
comprise a pointer (Including any necessary variables) 
to a predefined HLC sequence (hereinafter a imission 
script!) stored in the command script database 413. For 
example, a mission goal might comprise a single HLC 
requesting relocation of the spacecraft to a specified is 
destination by an indicated time. The mission manager 
403 uses a imission module! (a software module) which 
corresponds to the single HLC that is executed by the 
mission manager 403 to analyze the feasibility of carry- 
ing out the single HLC in view of system resources and so 
all other mission goals. If acceptable, the mission man- 
ager 403 stores the single HLC with other mission goals 
for future reference. e.g.. during the analysis of new 
mission goals. The mission manager 403 also sends 
the single HLC to the HLC processor 405 for further 25 
processing. 

If the mission goal comprises a pointer to a mission 
script the mission manager 403 selects a mission mod- 
ule which corresponds to the mission script, and. as 
with the single HLC mission goal, is used to perform an 30 
analysis of feasibility Of course, the mission module for 
the pointer might In turn invoke other mission modules 
that correspond to the underlying single HLCs making 
up the mission script. Likewise, the mission saipts 
stored within the command script datat)ase 413 may 35 
also contain pointers to other mission scripts stored 
therein. When processing such nested pointers, the 
mission manager 403 may again invoke further mission 
modules as needed to evaluate the underlying HLCs. 
Thus, missbn scripts might comprise one or more HLCs 4o 
together with one or more interleaving pointers to other 
mission scripts, one or more HLCs. or one or more 
pointers to other mission scripts. In this way, mission 
goals can be created at very high conceptual levels by 
leveraging off of more and more specific groupings of 45 
HLCs. Moreover, as a general rule, unless an encom- 
passing mission module has been written, the mission 
manager 403 will execute a mission module for each 
and every HLC underlying a mission goal. If the missbn 
goal comprising the pointer is acceptable, the mission so 
manager 403 stores the pointer with other mission goals 
for future reference, and forwards the pointer to the HLC 
processor 405 for further processing. 

Thus, the mission manager 403 contains a plurality 
of mission nrxxlules used by the mission manager 403 S5 
to analyze mission goals. Upon receiving a new mission 
goal, the mission manager 403 first verifies that it hais a 
corresponding misston module dedicated to servicing 



the new mission goal. If not, the new mission goal is 
rejected, and the mission manager 403 communicates 
the rejection to the source of the mission goal, e.g.. 
ground support or a ground based transmitter. Thereaf- 
ter or at any time, ground support can deliver to the mis- 
sion manager 403 new mission nxxlules for future use. 
Available mission modules may also be replaced or can- 
celed in the same manner. 

The fault analyst 409 also utilizes scripts and soft- 
ware modules. The fauH analyst 409 monitors data 
streams received from the flight manager 407, looking 
for spacecraft system faults. If detected, the fault analyst 
409 attempts to isolate the fault If successful, the fault 
analyst 409 selects one or more recovery scripts in the 
command saipt database 413. sends the HLC proces- 
sor 405 pointers thereto, and informs the mission man- 
ager 403. Further detail regarding this process of 
autonomous fault k^entification, isolation and recovery 
can be found in a U.S. Patent Applicatfon Serial No. 

, entitled "In Situ Method And 

System For Autononrious Fault Detection, Isolation AtkI 
Recovery," filed on even date herewith by Hanson et al. 
Such applk:ation is hereby incorporated herein by refer- 
ence in its entirety. 

As with mission goals, recovery saipts may com- 
prise one or a sequence of HLCs that are directed to 
placing at least part of the flight manager 407 or under- 
lying spacecraft hardware and/or software components 
or systems in a condition addressing the isolated fault. 
The fault analyst 409 also parses the command saipt 
database 413 and. as proves necessary, disables or 
modifies recovery, performance and mission scripts 
therein to accommodate the fault Modified or disabled 
scripts within the database 413 receive a flag indicating 
such conditions. 

Thereafter, if saipts have been modified or disa- 
bled, the fault analyst 409 infomns the mission manager 
403 and the mission analyst 41 1. In response, the mis- 
sion manager 403 first reexamines its pending missfon 
goals to determine whether a flag has been associated 
therewith. If not the mission manager 403 reanalyzes 
the pending mission goals to determine whether ade- 
quate system resources still remain. If adequate 
resources still remain, the mission manager 403 contin- 
ues to operate as tietore except with restrictions that 
might be applnable to new mission goals that may be 
received. 

If one or nx>re pending mission goals have been 
disabled by the fault conditfon. the mission manager 
403 relays such information to the requesting base sup- 
port systems, reschedules the remaining pending mis- 
sion goals, and directs the HLC processor 405 to 
remove the canceled mission goals from its queue. If a 
pending mission goal has been nxxjif led as indicated by 
a flag, the mission manager 403 reanalyzes the pending 
mission goals to determine whether adequate 
resources still exist tf so, the mission manager 403 
reports the status to ground si4)port and the HLC proc- 
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essor405. Otherwise, the mission manager 403 selects 
a set of pending mission goals that can be accom- 
plished, relays such information to ground support, and 
directs the HLC processor 405 to remove the remaining 
mission goals from its queue. Ground support may redi- 
rect the mission manager 403 if so desired to cancel 
and replace one or more of the selected pending mis- 
sion goals to Imake room] for more important others that 
were not selected. 

The mission analyst 411 also responds to an indi- 
cation of fault by checking to see if any performance 
saipts are in queue at the HLC processor 405 that have 
been flagged. If a flag indicates cancellation, the mis- 
sion analyst 411, like the mission manager 403. directs 
the HLC processor 405 to remove the performance 
script from queue. Afterwards, the mission analyst 41 1 
communicates the problem to ground support for assist- 
ance. Similarly, ground support as well as the HLC proc- 
essor 405 are contacted if a flag indicates modification. 

Additionally, the mission analyst 41 1 monitors sen- 
sor readings, actuator commands and spacecraft infor- 
nfiation to determine how well mission objectives are 
being performed. These objectives might include, for 
example, trajectory tracking, expected versus actual 
power usage, and expected versus actual fuel con- 
sumption. If an anomdous trend is detected. e.g.. any 
objective falling outside an allowable ranga the mission 
analyst 41 1 informs the mission manager 403. identifies 
con-esponding performance scripts (if available) from 
the command script database 413 and delivers any 
such scripts to the HLC processor 405 for queuing. The 
mission manager 403 responds by reanalyzing the 
pending mission goals to reconfirm their viability. Pend- 
ing mission goals that cannot be supported are 
removed from the queue of the HLC processor 405. 
Reports to ground support follow. 

The mission analyst 411 utilizes a series of iper- 
fomiance monitorsT which are software modules that, 
when enabled, monitor specific aspects of the underly- 
ing spacecraft systems. In response to HLCs received, 
the HLC processor 405 selectively enables ones of the 
available performance monitors as instructed. Scripts 
and goals call for enablement of specific performance 
monitors when relevant to underlying task. 

As menttoned. the HLC processor 405 receives 
mission goals containing single HLCs and pointers to 
mission sequences. It also receives recovery and per- 
formance saipts. The HLC processor 405 converts all 
such scripts and goals to HLCs. and places all of the 
HLCs in a queue in time ordered sequence. Upon 
receipt of an indication that a modification to one or 
more goals or scripts have been made, the HLC proces- 
sor 405 repeats this conversk>n and ordering process to 
address such modifications. Thus, as the execution time 
of an HLC approaches, the HLC processor 405 trans- 
lates the HLC Into oonresponding LLC sequences, and 
delivers the LLC sequences to the flight manager 407 
for execution at the appropriate time. 



The HLC processor 405 translates the HLC through 
access to a library of LLC sequences. Using the HLC as 
an index, the HLC processor 405 extracts an LLC 
sequence that canries out the desired functionality of the 
5 HLC. Each HLC has a corresponding library entry con- 
taining an LLC sequence corresponding thereto. As 
with the mission goals, the LLC sequences may also 
point to other LLC sequences and so on in a hierarchi- 
cal fashion. 

10 Therefore, a single HLC may actually deliver sev- 
eral LLC sequences to the flight manager 407. HLCs 
often include data or variables specific to the desired 
task at hand. The HLC processor 405 merges data or 
variables into the LLC sequences before delivering 

15 them to the flight manager 407. 

The HLC processor 405 correspondingly informs 
the fault analyst 409. the mission manager 403 and the 
mission analyst 41 1 when a recovery script, mission 
goal or performance saipt has begun execution and 

20 when it has completed. Compieted goals or scripts are 
removed from pending lists. Once execution begins, 
scripts or goals can be canceled, but may require cor- 
rective action to counter LLCs already executed. Typi- 
cally, such corrective action is specified by particular 

25 scripts associated with each HLC at issue, but may also 
be handled from ground support. 

The LLC library within the HLC processor 405 can 
be supplemented, modified or replaced at any time from 
ground support via the transceiver 401 and the mission 

30 manager 403 routing. Similarly, the scripts within the 
command script database 413 can be supplemented or 
othenAfise nxxfif led or canceled. 

The flight manager 407 comprises a low level con- 
troller 421 and a safe mode override module 423. The 

35 low level controller 421 receives LLCs from the HLC 
processor 405 for execution. Pursuant to the LLCs, the 
low level controller 421 controls the operation of the 
spaceaaftis hardware and/or software systems, sub- 
systems and components. The low level controller 421 

40 also gathers data from the sensors 41 5. for example, for 
delivery to the mission analyst 411 and f^ult analyst 
409. 

A safe mode override module 423 also monitors the 
gathered data. If a severe fault condition is detected, the 

45 safe nrKXle override module 423 will issue LLCs to the 
low level controller 421 directing the entry of the space- 
craft into a Isafe mode. ? awaiting ground support or the 
fault analyst 409 to recover the spacecraft. Thus, the 
safe mode override module 423 protects the spacecraft 

50 systems by minimizing potential damage resulting from 
a fault, but also protects the spacecraft systems from 
faults unexpectedly created or worsened by any portion 
of the autonomous control system. 

Fig. 5 is an exemplary flow diagram that illustrates 

55 much of the functionality of the mission manager found 
within the embodiment of the autonomous spaceaaft of 
Fig. 4 in accadance with the present invention. At a 
block 501. the mission manager waits in an kile (low 
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power) state for the occurrence of an event. If the event 
constitutes receipt of a new mission goat (MG). as indi- 
cated by a block 503. the mission manager exits the idle 
state to evaluate the mission goal at a block 505. As 
previously discussed, such evaluation takes into consid- 5 
eration other pending mission goals as well as the 
spacecraftis systems and resource status. 

If the new mission goal can be performed, the mis- 
sion manager branches from a decision block 507 to 
add the new mission goal to the list of pending mission 
goals at a block 509. Thereafter, at a block 511 . the mis- 
sion manager delivers the new mission goal to the HLC 
processor tor queuing and later execution by the flight 
manager. After delivering the new mission goal, the mis- 
sion manager may be configured to send a status report 
(an acknowledge in this case) to the source of the new 
mission goal at a block 512 before returning to the idle 
state at the block 501. If at the block 507 the mission 
manager determines that the new mission goal cannot 
be serviced, at a block 512 the mission manager sends 
a status report to the source and returns to the idle state 
at the block 501. 

Fault or performance messages received from the 
fault analyst or the performance analyst also trigger 
events, as indicated by blocks 513 and 515, respec- 
tively. The mission manager responds by exiting the idle 
state and branching to a block 517 to evaluate the 
impact of the underlying fault or performance problem, 
and/or recovery or performance script. If changes need 
to be made to the current list of pending mission goals, 
as determined at a block 519. the mission manager 
modifies the list at a block 521 . Thereafter, the mission 
manager informs the HLC processor of such changes at 
the block 511. reports to ground support at the block 
512 and returns to the block 501 to reenter the idle 
state. The mission manager also services routing 
requests as indicated at a block 523. LLCs. HLCs. 
scripts, program modules, etc.. are routed as indicated 
at the block 525, as discussed above with reference to 
Fig. 4. for example. 

Fig. 6 is an exemplary flow diagram that illustrates 
much of the functionality of the fault analyst and safe 
mode operations found within the embodiment of the 
autonomous spaceaaft of Rg. 4 in accordance with the 
present invention. At a t)lock 601 . the fault analyst selec- 
tively monitors sensor data, actuator commands, etc.. to 
identify fault oondition& If a fault is detected, as indi- 
cated by the event block 603. the fault analyst attempts 
to isolate the fauK at the block 605. If the fault coukf not 
be isolated, the fault analyst branches from a block 607 
to a block 609 to consider placing the spacecraft in a 
safe mode or safo state, depending on the severity of 
the fault. 

If the fault was successfully isolated, the fault ana- 
lyst branches to a block 613. and modifies any script 
within the command script database as proves neces- 
sary to accommodate the fault. Such modification may 
also take the form of disabling certain scripts that can- 



not othen^ise accommodate the fault. After reporting 
such modifications (if any) to ground support at a block 
615. the fault analyst attempts to kJentify a fault recov- 
ery saipt at a block 617. If identifiea; the fault analyst 
branches from a block 619 to a block 620 where the 
identified script is delivered to the HLC processor (also 
identified as the iHLCPO then reports the fault at a block 
61 1 before returning to the block 601 . If no fault recov* 
ery script is identified at the block 619. the fault analyst 
considers placing the spacecraft in a safe mode then 
reports and returns to monitor data as indicated by the 
blocks 609. 611 and 601. 

The HLC processor queues and executes recovery 
scripts received. If a recovery script proves unsuccess- 
ful, as identified for example by persistence of the fault 
condition at the block 603. the fault analyst reattempts 
fault isolation and recovery via the blocks 605 through 

620. if alternate recovery scripts are available. Other- 
wise, the fault analyst branches through to the bfock 609 
to consider placing the spacecraft in a safe mode. In this 
way, the fault analyst is able to try other recovery scripts 
if one or more recovery saipt candidates prove unsuc- 
cessful. 

At any time during an attempt to recover, the safe 
mode module may take over. Specifically, at a block 

621. the safe mode module monitors data to Identify 
severe faults. If identified, as indicated at a block 623. 
the safe mode module places the spacecraft in a safe 
mode and reports such status to ground support at the 
blocks 625 and 628. The safe mode module operates 
rather rapidly in comparison to the fault analyst and. 
therefore, acts to encapsulate the spacecraft from the 
autonomous control system and to minimize damage 
caused by fault. 

Rg. 7 Is an exemplary flow diagram that illustrates 
much of the functionality of the mission analyst found 
wKhin the embodiment of the autonomous spaceaaft of 
Fig. 4 in accordance with the present invention. At a 
block 701 , the mission analyst utilizes a plurality of iper- 
fomnance monitors!, that monita sensa readings, actu- 
ator commands and other spacecraft information to 
evaluate mission performance as directed by the HLC 
processor. Fa example, a different perfamance moni- 
tor (software module) might be enabled fa a thruster- 
t^ased control mode versus a wheel k)ased control 
mode. In particular, at a block 703. rf a command is 
received to enable or disable a performance monitor, 
the mission analyst branches to a block 705 to perform 
such command befae returning to the block 701 to con- 
tinue nx>nitoring by all enabled performance monitors. 

If an anomolous trend is detected in performance 
data being monitored as indfoated by an event block 
711. the mission analyst considers whether nKXIifica- 
tions to current scripts, goals a system operations 
shoukl be made at a block 713. If so. such modif foations 
are performed at the block 715 in the manner described 
above with reference to Rg. 4. Aftenwards. the mission 
analyst reports the modifications to ground 8if)port and 
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the mission analyst, and returns to the block 701 to con- 
tinue enabled monitoring tasks. If the mission analyst 
identifies trends or anomalies rising to a problematic 
level, as indicated a1 a block 721, and cannot service 
the problem via the blocks 723 and 715, the mission s 
analyst may resort to placing the spacecraft in a safe 
mode at a block 725 and await ground support direction. 

In view of the above detailed description of the 
present invention and associated drawings, other modi* 
fications and variations wilt now become apparent to io 
those skilled in the art. For example, although the func- 
tionality associated with autonomous control as 
described herein is illustrated in context of spacecraft 
embodiments, such functionality could also be placed 
within any remote non-spacecraft system which does is 
not lend ttseff to non-autonomous approaches for fault 
management, e.g.. aircraft, submarines or power plants. 
Also, the use of an HLC processor, although desirable in 
the embodiments illustrated, need not be included in the 
autonomous control system. Instead, one or more of the so 
fault analyst, mission analyst and mission manager 
couU directly generate and deliver LLCs to the flight 
manager. Likewise, the functionality of the HLC proces- 
sor or any of the autonomous control system could be 
othenvise combined or distrbuted in many ways. It 25 
should be apparent that such and other modifications 
and variations may be effected in the embodiments 
described herein without departing from the spirit and 
scope of the present invention as set forth in the claims 
which follow. 30 

Claims 

1. A spacecraft system having a ground-based sys- 
tem and a spacecraft, having an operational status. 3s 
used to carry out a plurality of mission objectives, 
the spaceaaft comprising: a plurality of actuators; 

a plurality of sensors that produce data indica- 
tive of the operational status of the spacecraft; 4o 
a flight manager, coupled to the plurality of 
actuators and the plurality of sensors, that con- 
trots the plurality of actuators pursuant to any of 
a plurality of k)wer level commands; a trans- 
ceiver capable of receiving both selected ones 4S 
of the plurality of lower level commands from a- 
ground'based system destined for the flight 
manager, and selected ones of a plurality of 
higher level commands that represent the plu- 
rality of mission objectives; so 
an autonomous control system, communica- 
tively coupled to the flight manager, that auton- 
omously attempts to carry out the plurality of 
mission objectives through scheduling and 
occastonalty rescheduling of the selected ones ss 
of the plurality of higher level commands 
received by the transceiver; and the autono- 
mous control system generates, from the 



selected ones of the plurality of higher level 
commands, sequences of lower level com- 
mands that are delivery to the flight manager. 

2. The spacecraft system of claim 1. wherein the 
autonomous control system comprises a fault 
detectton and recovery module that analyzes the 
data produce by the plurality of sensors to detect 
and attempt recovery from fault conditions in the 
operational status of the spacecraft, and/or wherein 
the autorx)mous control system comprises a per- 
formance analyst that analyzes the data produce by 
the plurality of sensors.to detect and attempt 
accommodation of unexpected performance in the 
operational status of the spacecraft, and/or wherein 
the autonomous control system comprises a com- 
mand processor that perfornrts the generation, from 
the selected ones of the plurality of higher level 
commands, the sequences of k>wer level com- 
mands tfuit are delivery to'fte flight manager. 

3. In the spacecraft system of claim 2. the autono- 
mous control system further comprising a mission 
agent that responds to the fault detection and 
recovery module by attempting to reschedule the 
selected ones of the plurality of higher level com- 
mands to accommodate detected fault conditions. 

4. in the spacecraft system of claim 2. the autono- 
mous control system further comprising a mission 
agent that responds to the performance analyst by 
attempting to reschedule the selected ones of the 
plurality of higher level commands to accommodate 
the unexpected performance detected. 

5. A spacecraft, having an operational status, used to 
carry out a plurality of mission objectives, the 
spaceciBft comprising: 

a plurality of sensors producing data Indicative 
of the operational status of the spacecraft; 
a plurality of actuators; 

a controller, communicatively coupled to con- 
trol the plurality of actuators, that operates pur- 
suant to instructions received; 
an analyzer communicatively coupled to the 
plurality of sensors to monitor and evaluate the 
data produced; and 

a mission manager, communicatively coupled 
to tiie analyzer, that schedules and occasion- 
ally reschedules instructions for the controller 
to autonomously carry out the plurality of mis- 
sion objectives. 

6. The spaceaaft of claim 5 wherein the analyzer 
comprises 

a fault detection and recovery module that ana- 
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l/zes the data produce by the plurality of sen- 
sors to detect arKi attempt recovery from fauit 
conditions in the operational status of the 
spacecraft, and/or 

wherein the analyzer comprises a performance 5 
analyst that analyzes the data produce by the 
plurality of sensors to detect and attempt 
accommodation of unexpected performance in 
the operational status of the spacecraft. 

10 

7. The spacecraft of daim 6 wherein the mission man- 
ager responds to the fault detection and recovery 
module by attempting to reschedule the instructions 
for the controller to accommodate detected fault 
conditions. is 

8. The spaceaaft of claim 7 wherein the analyzer fur- 
ther comprises a performance analyst that ana- 
lyzes the data produce by the plurality of sensors to 
detect and attempt accommodation of unexpected 20 
performance in the operational status of the space- 
craft, and/or 

wherein sequences of the instructions are stored 
within the spacecraft in a hierarchical arrangement. 

25 

9. A spacecraft, having an operational status, used to 
canry out a plurality of mission objectives, the 
spacecraft conrprising: 

a plurality of actuators: 30 
a plurality of sensors producing data indicative 
of the operational status of the spacecraft: 
an analyzer communicatively coupled to the 
plurality of sensors to monitor and evaluate the 
data produced: and 3s 
a mission manager, communicatively coupled 
to the analyzer, that schedules and occasion- 
ally reschedules higher level instructions to 
autonomously carry out the plurality of mission 
objectives; 40 
a comn^and processor, communicatively cou- 
pled to receive scheduled higher level instruc- 
tions from the mission manager, that generates 
lower level instructions from the higher level 
Instructions received; and 45 
a control module, communicatively coupled to 
control the plurality of actuators, that operates 
pursuant to lower level instructions received 
from the command processor. 

so 

10. The spacecraft of claim 9 wherein the analyzer 
comprises a fault detection and recovery-nrxxlule 
that analyzes the data produce by the plurality of 
sensors to detect and attempt autonomous recov- 
ery from fault conditions in the operational status of ss 
the spacecraft, and/or 

wherein the analyzer comprises a performance 
analyst ttiat analyzes the data produce by the plu- 



rality of sensors to detect and attempt accommoda- 
tion of unexpected performance in the operational 
status of tiie spacecraft, and/or 
wherein sequences of tiie higher level instructions 
are stored wittiin the spacecraft in a hierarchical 
arrangement. 

11. The spacecraft of daim 10 further comprising a 
library that contains sequences of the lower level 
instructions, and the command processor gener- 
ates lower level instructions for each of the higher 
level instructions by referendng the library. 

12. A spacecraft system having a spacecraft, with an 
operational status, capable of carrying out a plural- 
ity of mission objectives, the spacecraft system 
comprising: 

a plurality of ground units each having a ground 
transceiver; a plurafrty of actuators disposed on 
the spaceaaft; a plurality of sensors, disposed 
on tiie spacecraft, that produce data indicative 
of the operational status of the spacecraft; 
a flight manager, disposed on the spacecraft, 
that controls the plurality of actuators pursuant 
to any of a plurality of lower level commands; 
a spacecraft transceiver, disposed on tiie 
spacecraft, capable of receiving and routing 
ones of the plurality of lower level commands 
from at least one of tiie plurality of ground units 
to the flight manager; 

an autononfx>us control system, disposed on 
the spacecraft and communicatively coupled to 
both ttie flight manager and the spaceaaft 
transceiver, tiiat autonomously carries out 
ones of tiie plurality of mission objectives 
through receipt, scheduling and occasionally 
rescheduling of higher level commands; and 
the autonomous control system translates the 
higher level commands into sequences of 
lower level commands tor delivery to tiie flight 
manager. 

13. The spacecraft system of daim 12 wherein the at 
least one of the plurality of ground units comprises 
a ground support system. 

14. The spacecraft system of daim 13 wherein at least 
one other of the plurality of ground units conrprises 
a transmitter having a user interface to initiate deliv- 
ery of one or more higher level commands to the 
autonomous control system via the spacecraft 
transceiver. 

15. The spaceaaft of claim 14 wherein the autono- 
mous control system comprises a fault detection 
and recovery nxxiule that analyzes tiie data pro- 
duce by the plurality of sensors to detect and 
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attempt autonomous recovery from fault conditions 
in the operational status of the spacecraft 

16. The spacecraft of claim 15 wherein the autono- 
mous control system further comprises a perfam- s 
ance analyst that analyzes the data produce by the 
plurality of sensors to detect and attempt accom- 
nxxlation of unexpected performance in the opera- 
tional status of the spacecraft. 
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